Best Practices in Business Rules

Overview

Bizagi provides powerful Business rules that can be implemented in various places throughout the Process to perform actions, route your Processes, manage user interfaces, and allocate users.

There are many ways to define a rule and have the exact same results. You should implement the most efficient and flexible one.

This section provides some guidelines to build rules focused on minimizing the impact on the performance of the application and enabling Processes to easily adapt to changing business conditions.

General Guidelines

• All business rules for routing processes are built in Bizagi

• If a business rule exists in another system

  • Request the customer to expose the business rule and consume it from Bizagi
    • Recommendation: Using web services
    • Alternative 1: Using the Bizagi component library as a facade.
      • Invoking an API provided by the customer
      • Using a component to access an external data source (i.e. stored procedures)
  • If the system will be replaced in a short time
    • Recommendation: Build the logic in Bizagi.

• If a business rule has high computational demand

  • It should be implemented on another system and consumed from Bizagi
    • Recommendation: Implement it as a web service
    • Alternative 1: Using the Bizagi component library as a facade.
      • Invoking an API provided by the customer
      • Using a component to access an external data source (i.e. stored procedures)

• If a business rule is changed frequently by business users

  • It can be done inside or outside Bizagi
    • In Bizagi, if there is no other system that can implement it or it doesn’t have a user interface that allows modification by business users
    • In an external system, if it has an interface for business users and can be consumed from Bizagi
      • Recommendation: Implement as web services.
      • Alternative 1: Using the Bizagi component library as a facade.
        • Invoking an API provided by the customer
        • Using a component to access an external data source (i.e. stored procedures)

• If a new business rule is required and must be consumed from other systems

  • You can build it in Bizagi if it is not of high computational demand
  • Other systems may access it through the SOA layer (just business rules, this does not apply to expressions or functions)

Nomenclature for Expressions

Using prefixes in rules has two roles: explain the purpose of the rule and where it’s been used; follow this guide to select the appropriate prefix:

Rule Type	Prefix	Example
Visibility, required, editable, transition	Is_	Is_CustomerVIP, Is_Allowed
Button Rule	Exe_	Exe_CalcRates
Event Rule (On Enter, On Exit)	Evt_	Evt_ProcessElements
Event Rule (On Save, Submit on change)	Sav_	Sav_RecalculateFlags
Library Rules		Finance.CreateElements, Common.FilterElements
Filter Rules	Fil	Fil_CustomerVIP, Fil_Requests

Designing Efficient and Governable Business Rules

When defining business rules, you should take into account the following basic principles:

1. Design Flexible Rules
2. Implement Efficient Code
3. Document Rules

Below you will find useful guidelines to follow these principles and aid the rules definition and administration.

1. Design Flexible Expressions

Business rules are used to model business conditions. As these conditions are in constant change, it is fundamental to create rules that can be easily changed.

Plan carefully which changes your Process may face and build rules in a way they can be easily adapted to respond to the changing business conditions.

Use Policies

Use Policies to model business rules that face changing business conditions. Using policies instead of Expressions offers the advantage of allowing users to easily manage them from the Work Portal. This way, they can perform changes in values or logic in real-time to instantly adapt to the current business conditions.

The image below shows an Expression and a decision table (Policy) used to evaluate the risk assessment of a loan application based on a credit assessment. Both expression and decision table work for this purpose, but if the values of the risk assessment change to respond to the business conditions, you cannot access the expression from the production environment to modify them. In contrast, by using a decision table, users can easily change these values from the Work Portal.

Use Vocabularies

Vocabularies are definitions that obtain or set all the information used in the Policies or Expressions. If a business rule cannot be modeled as a Policy, but their parameters need to be frequently changed for adapting to the business conditions, you can use Expressions including Vocabularies.

Vocabularies can be invoked from Expressions or Policies and managed in the production environment by end users from the Work Portal.

The image below shows two ways to assign the duration to an activity. The duration of this activity depends on a customer SLA (Service Level Agreement).

In the upper image, the activity duration is defined as a fixed value. If the SLA changes, the expression has to be modified in the development environment and then be taken to the production environment via deployment.

In the lower image, a Vocabulary is used to define the duration. If the SLA changes, an administrator user can access the Work Portal and modify the value of the vocabulary to instantly reflect the new condition in the Process.

Do not Assign an Entity Instance by Using Their ID

When having an entity instance, do not assign it with an ID. You will have to use objects instead.

Reuse Business Rules

Business rules can be reused along a Process. In many cases, the same logic is followed in different steps of the Process and does not make sense to build the same rule over and over again. Reuse rules everywhere they are needed, this way if changes are required you only modify them once and reflect changes everywhere the rule is used.

Use Library Rules

Library rules are reusable for the entire project, as they are defined globally. In Library rules, it is mandatory to use the first parameter as Me and NO other object.

Declare All Variables

Use the expression element to declare the variables that will be used in the Expression, giving each one a type, and an initial value.

2. Implement Efficient Code

Some complex situations may require you to implement code in Bizagi. For these cases, take into account that there are practices that highly affect the performance of the application. Keep these practices in mind when implementing business rules to make your application faster and improve the user experience:

• Avoid manipulating plenty of records at once
  When using methods to obtain a set of records, make sure that filters are used accordingly and that you only fetch those records which you really need.

• Avoid nested for's
  Nested iterations may take a long time to process and create performance issues.

• Avoid the combination of the following functions in a single expression/sentence:

  • An iteration (for) within the iteration addRelation and removeRelation functions
  • Within the iteration, using Collection Xpaths with filters

• Avoid handling attachments in rules
  Keep in mind that handling attachments directly within business rules will most likely involve working with bytes. In many instances, these attachments will have a large file size, and this could demand more resources by the application resulting in performance inadequacies.

• Avoid using CEntityManager method to manipulate entities other than Parameter entities
  When use of XPath does not apply for the business requirement and use of CEntityManager and its methods is strictly needed, make sure you always include filters.

• Avoid the use of several expressions executed On save / Avoid On Save expressions with heavy processing workload
  On save expressions are executed each time the form is saved or a submit on change is executed. If there are complex calculations or patterns that take a long time to process on save, the Work Portal may present performance problems.

3. Document Business Rules

Many people can work on a Process during its lifecycle. Business rules must be built in a way that any person can understand the logic followed and its real purpose. Take into account the following guidelines to make the understanding of business rules a lot easier:

Give Expressions a Name and Description

Being able to identify the purpose of a rule is very important to ensure the understanding of the logic followed by a Process and to enable their reusability along Processes. Always fill the name and description properties of rules in a clear manner that describes its main purpose and any other relevant information.

Comment Code

Frequently, when code is used, understanding what someone else wrote before you might be a challenge. Each person has their own point of view and captures business logic in rules in different manners.

When you use code in expressions, take into account that you will not be the only person who needs to understand the logic followed. Use comments to describe the purpose of your code lines in expressions and save time and effort for other people trying to understand the way a condition was modeled.

The following images show an expression with and without comments. Note how easy it is to understand the logic of the expression when using comments.